-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
performance: cache parsed markers, constraints and versions #556
performance: cache parsed markers, constraints and versions #556
Conversation
looks fine to me though fwiw I don't reproduce any performance delta on the "big" install that I have lying around. |
if this is real: I wonder whether constraint parsing and version parsing would similarly benefit |
Great idea. Although there is more variance in constraints and versions than in markers, it makes a significant difference, too. I updated the times in the PR description. Further, I tested the change on another largish (non-public) project:
Cache info for private project:
The peak memory usage even decreased when caching constraints and versions. |
42b5daa
to
4639236
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Some more fallout from #530. The parsing of marker strings became a bit slower with measurable effects in real-world examples. It seems in real-world examples, the same marker is used many times for different dependencies. Since markers are immutable, we can just cache the parsed markers and mitigate the performance regression.
Performance for shootout example with warm cache:
(There seems to be no significant increase in peak memory usage due to the caching.)
Update: added times for caching parsed constraints and versions in addition to markers.